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Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD)
        in Transparent Interconnection of Lots of Links (TRILL)

Abstract

   Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD)
   is designed to verify multipoint connectivity.  This document
   specifies the support of P2MP BFD in Transparent Interconnection of
   Lots of Links (TRILL).  Similar to TRILL point-to-point BFD, BFD
   Control packets in TRILL P2MP BFD are transmitted using RBridge
   Channel messages.  This document updates RFCs 7175 and 7177.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8564.
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   Copyright (c) 2019 IETF Trust and the persons identified as the
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   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
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1.  Introduction

   TRILL supports multicast forwarding.  Applications based on TRILL
   multicast may need quick detection of multicast failures using P2MP
   BFD [RFC8562].  This document specifies TRILL support of P2MP BFD.

   To use P2MP BFD, the head end needs to periodically transmit BFD
   Control packets to all tails using TRILL multicast.  A new RBridge
   Channel message is allocated for this purpose.

   In order to execute the global protection of distribution used for
   multicast forwarding [TRILL-TREES], the head needs to track the
   active status of tails [RFC8563].  If the tail loses connectivity as
   detected by not receiving the new RBridge Channel message from the
   head, the tail should notify the head of the lack of multipoint
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   connectivity with unicast BFD Control packets.  These unicast BFD
   Control packets are transmitted using the existing RBridge Channel
   message assigned to BFD Control [RFC7175].

   This document updates [RFC7177] as specified in Section 3 and updates
   [RFC7175] as specified in Sections 4 and 5.

2.  Acronyms and Terminology

2.1.  Acronyms

   Data Label:  VLAN or Fine-Grained Label [RFC7172].

   BFD:   Bidirectional Forwarding Detection

   P2MP:  Point to Multipoint

   TRILL: Transparent Interconnection of Lots of Links or Tunneled
          Routing in the Link Layer

2.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Familiarity with [RFC6325], [RFC7175], and [RFC7178] is assumed in
   this document.

3.  Bootstrapping

   The TRILL adjacency mechanism bootstraps the establishment of one-
   hop TRILL BFD sessions [RFC7177].  Multi-hop sessions are expected to
   be configured by the network manager.  A slight wording update to the
   second sentence in Section 6 of [RFC7177] is required.

   It currently reads:

      If an RBridge supports BFD [RFC7175], it will have learned whether
      the other RBridge has BFD enabled by whether or not a BFD-Enabled
      TLV [RFC6213] was included in its Hellos.
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   Now it should read:

      If an RBridge supports BFD (see [RFC7175] and [RFC8564]), it will
      have learned whether the other RBridge has BFD enabled by whether
      or not a BFD-Enabled TLV [RFC6213] was included in its Hellos.

   In addition, a normative reference to this document is added to RFC
   7177 as a result of this update.

4.  A New RBridge Channel Message for P2MP BFD

   RBridge Channel protocol number 0x002 is defined for TRILL point-to-
   point BFD Control packets in [RFC7175].  That RFC states that if the
   M bit of the TRILL Header of the RBridge Channel packet containing a
   BFD Control packet is nonzero, the packet is generally dropped.  In
   P2MP BFD, the head is required to probe tails using multicast.  This
   means the M bit will be set to 1.  For this reason, a new RBridge
   Channel message (P2MP BFD Control), whose protocol code point is
   0x007, is specified in this document.  An RBridge that supports P2MP
   BFD MUST support the new RBridge Channel message for P2MP BFD.  The
   capability to support the RBridge Channel message for P2MP BFD, and
   therefore support performing P2MP BFD, is announced within the
   RBridge Channel Protocols sub-TLV in Link State PDUs (LSPs)
   [RFC7176].

   As specified in [RFC7178], when the tail receives TRILL Data packets
   sent as BFD RBridge Channel messages, it will absorb the packets
   itself rather than deliver these packets to its attached end
   stations.

5.  Discriminators and Packet Demultiplexing

   The processing in Section 3.2 of [RFC7175] generally applies except
   that the test on the M bit in the TRILL Header is reversed.  If the M
   bit is zero, the packet MUST be discarded.  If the M bit is one, it
   is processed.

   After the processing per Section 3.2 of [RFC7175], the tail
   demultiplexes incoming BFD packets based on a combination of the
   source address and My Discriminator as specified in [RFC8562].  In
   addition to this combination, TRILL P2MP BFD requires that the tail
   use the Data Label, which is either the inner VLAN or the Fine-
   Grained Label [RFC7172], for demultiplexing.  If the tail needs to
   notify the head about the failure of a multipath, the tail is
   required to send unicast BFD Control packets using the same Data
   Label as used by the head.
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6.  Tracking Active Tails

   According to [RFC8562], the head has a session of type MultipointHead
   that is bound to a multipoint path.  Multipoint BFD Control packets
   are sent by this session over the multipoint path, and no BFD Control
   packets are received by it.  Each tail dynamically creates a
   MultipointTail per a multipoint path.  MultipointTail sessions
   receive BFD Control packets from the head over multipoint paths.

   An example use is when a multicast tree root needs to keep track of
   all the receivers as in [TRILL-TREES]; this can be done by
   maintaining a session of type MultipointClient per receiver that is
   of interest, as described in [RFC8563].  See [RFC8563] for detailed
   operations of tracking active tails.

7.  Security Considerations

   Multipoint BFD provides its own authentication but does not provide
   encryption (see the Security Considerations in [RFC8562]).  As
   specified in this document, the point-to-multipoint BFD payloads are
   encapsulated in RBridge Channel messages that have been extended by
   [RFC7978] to provide security.  [RFC7978] provides encryption only
   for point-to-point extended RBridge Channel messages, so its
   encryption facilities are not applicable to this document.  However,
   [RFC7978] provides stronger authentication than that currently
   provided in BFD.  Thus, there is little reason to use the BFD
   security mechanisms if authentication per [RFC7978] is in use.  It is
   expected that a future TRILL document will provide for group keying;
   when that occurs, the use of RBridge Channel security [RFC7978] will
   be able to provide both encryption and authentication.

   For general multipoint BFD security considerations, see [RFC8562].

   For general RBridge Channel security considerations, see [RFC7178].

8.  IANA Considerations

   IANA has allocated the following from the Standards Action [RFC8126]
   range of the "RBridge Channel Protocols" registry, which is part of
   the "Transparent Interconnection of Lots of Links (TRILL) Parameters"
   registry.

          Protocol          Number
          ----------------  ------
          P2MP BFD Control  0x007
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